Is there a git log syntax for displaying the output of a list of commits, such as commits between ref1 and ref2, or 10 commits leading up to and after a ref, or made within a certain time of the ref?
git log SHA_HASHREF1..SHA_HASHREF2
has always worked for me for displaying between two specific commits
Hey look, documentation http://git-scm.com/docs/git-log :)
You can use the following parameters to figure out commits within the time of the ref
--since=<date>
--after=<date>
Related
I'm trying to see all modifications made from 06e27fd143240e8e4d13b29db831bedece2bf2d3 to the latest e1c34175b5556ac5ce1e60ba56db2493dd9f6b52. I tried
https://github.com/gaganmalvi/kernel_xiaomi_lime/compare/Q:e1c34175b5556ac5ce1e60ba56db2493dd9f6b52%5E%5E%5E%5E%5E...Q:06e27fd143240e8e4d13b29db831bedece2bf2d3
and vice-versa but it does not work.
Also I tried https://github.com/gaganmalvi/kernel_xiaomi_lime/compare/06e27fd143240e8e4d13b29db831bedece2bf2d3%5E%5E%5E%5E%5E...Q which seems to work but brings changes from 2017, but the changes I want to see are from dec 2020 and beyond.
Your compare URL could be something like
https://github.com/gaganmalvi/kernel_xiaomi_lime/compare/Q..02ca1a9
Q is the name of the only branch in that repository. It is used here for the HEAD of the repository.
02ca1a9 is the "Git Object ID" for the state of the repository after the last commit in Dec 2020.
GitHub documentation for comparing commits
To compare commits in GitHub, there are two options, sharing the syntax with the git diff syntax:
A..B to show the difference between commit A and B (this is equivalent to diff A B)
A...B to show the difference between "merge base of A and B" and B (this is indeed equivalent to diff $(merge-base A B) B
GitHub URLs:
Comparing commits directly: https://github.com/gaganmalvi/kernel_xiaomi_lime/compare/06e27fd143240e8e4d13b29db831bedece2bf2d3..e1c34175b5556ac5ce1e60ba56db2493dd9f6b52
Comparing from merge base: https://github.com/gaganmalvi/kernel_xiaomi_lime/compare/06e27fd143240e8e4d13b29db831bedece2bf2d3...e1c34175b5556ac5ce1e60ba56db2493dd9f6b52
Does
git diff e1c34175b5556ac5ce1e60ba56db2493dd9f6b52 06e27fd143240e8e4d13b29db831bedece2bf2d3
not work?
I want to view all the commits for a given "directory" and after a given date, in Github. I have read Github API documentation and "path" and "since" parameters do the job. https://developer.github.com/v3/repos/commits/#list-commits-on-a-repository
However, I am not able to view them on Github. "Since" parameter seems not to work on Github. Example: https://github.com/torvalds/linux/commits?path=Documentation&since=2016-04-04T16:00:49Z
Any idea how can I achieve this?
Thanks,
Leticia
Command line:
Use git log --since option.
git log --since="2015-12-01"
This will tell all commits/actions since December 01 2015. Checkout link
Git commit history
EDIT:
Git hub:
As per my research, there is no trivial solution to view github commits "after" a particular day. You can however use compare option to compare repo/branches between two time periods, this will give you a view of commits "after" particular day.
E.g: The following compares branches between two time periods, thereby listing all commits between this period.
https://github.com/torvalds/linux/compare/master#{2016-04-14}...master#{2016-04-25}
Hope, this helps!
Note: I would recommend command line when possible as it definitely gives you more flexibility.
You could use either this:
git log -- path/ --since="date"
Or this to check a file history
git log -- path/myfile.txt --since="date"
In github you would have to do this:
https://github.com/torvalds/linux/commits/master#{date}/Documentation
for your particular example:
https://github.com/torvalds/linux/commits/master#{2016-04-04T16:00:49Z}/Documentation
I have been fumbling around on github, and now with some help I have managed to make my branch the local master. however, I get these lines that i guess are tracking where things have been changed. But I don't want them!! I really just want my current files to become the new master as they are.
What exactly are these lines for? And how do I suppress them?
<<<<<<< HEAD
=======
>>>>>>> master
Those lines signal merge conflicts in Git.
When you do a merge, git is generally good at automatically working out how to merge files together, however there are some cases where it cannot - for example, when both branches are adding to the same kind of area in the same file, you get a merge conflict.
In these cases, those lines will be drawn around the boundary of the conflict. The section above the ======= belongs to the HEAD ref (or whatever is displayed after <<<<<<<). The section below belongs to the master ref (or whatever is displayed after >>>>>>>).
It's up to you to delete these lines and make the according edit to the code. If you only want to take what is on the HEAD ref in the final version of the code (post-merge), then you delete everything below the ====== line - and visa versa if you want to only take what is on the master branch. Of course, you can also take both versions of the code by just removing the markers.
You can see the git manual for more information.
Say if I have a good revision: 3200. Then I want to test something, and since it has 10 lines of change, and I need to remove a few lines, even though I am still testing I commit first, and after some changes, commit again, and let's say, I did 6 commits.
Now I want to put this on hold, but I don't want to lose all the testing and code written, so I want to
$ hg up -r 3200
which is the good, stable revision I want, and now can I commit and push as the tip? (if possible I want to avoid backing out hg backout because it looks bad somewhat, and I don't want to rollback because rollback has side effect of "if someone pulled from me during this time, the change can somehow get back in the repo")
Putting things on hold can be done in several ways in Mercurial. The simplest way is to simply not push it anywhere. After you go back in history with
$ hg update 3200
you can use
$ hg push -r .
to push only up to revision 3200. The . is important — it means the working copy parent revision, which in this case is 3200. Revision 3200 wont be "tip" in your local repository since you still have revisions 3201–3206, and the highest numbered revision is always what we call "tip". In other words, the history looks like this:
[3199] -- [3200] -- [3201] ... [3205] -- [3206]
^ ^
"." "tip"
where I've marked the current working copy parent revision and the tip revision.
When you start working based on revision 3200, the graph will change into
[3199] -- [3200] -- [3201] ... [3205] -- [3206]
\
\-------------------------------- [3207]
^
".", "tip"
Please try not to add too much emphasis on "tip". It changes all the time and is generally not very interesting. If you jump back to 3206 and make a commit, then tip will denote the newly created revision 3208 in your repository. In another repository, tip can be something else, depending on what was pulled from you and when it was pulled.
If you often need to do hg push -r ., then I suggest you create an alias for it. Such an alias would be a gentler push and could therefore be called "nudge":
[alias]
nudge = push -r .
With that in your toolbox, you can always do
$ hg nudge
to send the changesets you've just created up to the server, without worrying about sending up any other branches that you might have put on hold.
Finally, remember that you can use
$ hg update 3206
$ hg commit --close-branch -m "Abandoning this line of development"
to mark the 3206 changeset as "closed". This means that it wont show up in hg heads and it wont be considered for merging when you run hg merge. You will need to use hg push --force if you push it to the server, but and is okay since you're not creating multiple open heads, you just add another closed head.
The trouble with multiple open heads is really that a new hg clone might update to one of them and that would be confusing — people wouldn't know where to start working. With recent versions of Mercurial, hg clone won't update to closed heads so you avoid this problem.
You can re-open a closed head by simply making a child commit based on it. This means that you can close a line of development temporarily with no ill effects, other than a note in the graph saying that the branch was closed at some point.
From the question and the accompanying comments, it sounds like you want all new changes to be based on 3200, leaving previous work based on 3200 as a separate branch. It's easy to do:
hg up 3200
# work work
hg ci -m "new work based on 3200"
but there isn't any way to mark 3200 as tip, as far as I can tell. Once you commit something based on 3200, that new changeset will be tip, so you could make some benign change and commit that to create the new tip, but that's kind of kludgy. Another option if you are concerned that fellow collaborators won't know to use 3200 as the basis for their work because mercurial won't have it marked as tip is to give it a tag and tell team members to make sure and update their working copy to that tag before beginning their work.
krupans answer is of course correct, and he already mentions the problem of having now two head. But I'd like to stress that you will then have two heads of the same branch, and it could be difficult for other people to understand what's going on, and which head to use.
For this reason, it might be beneficial to put your testing code into a new branch, and for that you'll have to rewrite the history. You can do this with the MQ extension (assuming 3201 is the child revision of of rev 3200, and 3206 is the last of your testing commits:
hg qimport -r 3201:3206
hg qpop -a
hg branch branchname
hg qpush -a
hg qfinish -r 3201:3206
Try this out on a clone of your repo!
This should only be done if you haven't already pushed these changes to some other places.
I understand that CVS is obsolete system in out time but my company use it.
Problem is the next. As usual when developing starts we create branch from head and start work. Some times later we re-base branch with head and merge head with branch. It is ok. But every next typically operations are with problem. Many-many files are marked as changed, but in fact files hasn't any changes! . And these files aren't become white they red. It's a problem, because we need to review all of it to be sure that file modified.
To re-base branch with head we have do (using WinCVS):
1.Click Update.. on some branch;
2.Check Create missing directories;
3.Check Get the clean copy;
4.Check Update using last check in time;
5.Select Revision to update;
6.Select Merge type.
Any ideas why this can happen?
Thanks.
Tag the HEAD after each rebase, and next time you rebase, set the root tag to the last tag you made.
Like this:
Create BRANCH from HEAD, tag HEAD with BRANCH_ROOT_1
Do some work in HEAD
Merge HEAD into BRANCH with root branch BRANCH_ROOT_1, tag HEAD with BRANCH_ROOT_2
Do some more work in HEAD
Merge HEAD into BRANCH with root branch BRANCH_ROOT_2, tag HEAD with BRANCH_ROOT_3
...
GIT and (recently) SVN do this sort of thing automatically, but with CVS you need to do it manually after each merge. It's one of many reasons CVS is to be avoided like the plague.
I would suggest checking line endings (Win/Unix).
I have seen problems with all files marked as changed because of time zone problems. For example files checked out on a server using UTC, and copied over the network to a pc using CET. Or a change in daylight savings time caused such problems.
I have always used TortoiseCVS and it's Merge command, so I don't know much about WinCVS.